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Abstract 

People change the identifiers through which they are 
reachable online as they change jobs or residences or 
Internet service providers. This kind of personal mobil- 
ity makes reaching people online error-prone. As people 
move, they do not always know who or what has cached 
their now obsolete identifiers so as to inform them of the 
move. Use of these old identifiers can cause delivery fail- 
ure of important messages, or worse, may cause delivery 
of messages to unintended recipients. For example, a 
sensitive email message sent to my now obsolete work 
address at a former place of employment may reach my 
unfriendly former boss instead of me. 

In this paper we describe HINTS, a historic name- 
trail service. This service provides a persistent way to 
name willing participants online using today's transient 
online identifiers. HINTS accomplishes this by connect- 
ing together the names a person uses along with the 
times during which those names were valid for the per- 
son, thus giving people control over the historic use of 
their names. A correspondent who wishes to reach a 
mobile person can use an obsolete online name for that 
person, qualified with a time at which the online name 
was successfully used; HINTS resolves this historic name 
to a current valid online identifier for the intended re- 
cipient, if that recipient has chosen to leave a name trail 
in HINTS. 



1 Introduction 

The online world is inhabited by nomads. People 
change their online names as they switch Internet 
service providers (ISPs), either because they change 
jobs and they use the ISP of their employer, or be- 
cause they switch to a better, cheaper, or more con- 
venient service for their personal ISP. As a result, 
people accumulate a legacy of online identifiers that 
are, in most cases, dangling pointers into obscurity, 
making it hard to reach people. 

Unfortunately, sometimes an obsolete online iden- 
tifier does point to something, and this can be much 



more dangerous than a dangling identifier. If the 
obsolete identifier belongs to my previous personal 
ISP, then some unrelated, unfortunate subscriber of 
that same ISP is bothered by my legacy of spam. If 
the obsolete identifier belongs to my previous place 
of employment, it might allow my sensitive commu- 
nications to reach a potentially disgruntled former 
colleague or boss. 

The problem stems from the simple fact that on- 
line identifiers do not belong the people that they 
name; they belong to the organization that manages 
the associated name space. An employee of Sample 
University does not own her Sample U. email ad- 
dress; that address belongs to the university itself, 
which loans it out to its employee for the duration 
of her employment there. Similarly, my yahoo . com 
address only names me as long as Yahoo! allows me 
to use it and maintains its service. This is essentially 
a mobility problem: a mobile person moves slowly 
from identifier to identifier in a potentially-changing 
landscape of online names over which he has lit- 
tle control or authority. We call this the personal- 
identity mobility problem. 

The promise of unique personal identifiers as a 
panacea for all kinds of identity mobility has been 
made many times with dubious success. In some 
cases, the proposed identification scheme requires a 
retrofit of the entire communications infrastructure 
of the Internet to work ||l2|. In other cases, the 
"unique personal identifier" is just another identifier 
assigned from a proprietary name space |l^, |l8[ 

H- 

In this paper we propose the Historic Name- 
Trail Service (HINTS). In our naming scheme, cur- 
rent online identifiers, email addresses and instant 
messaging account names remain the primary iden- 
tifiers that people use in everyday communications. 
However, HINTS enables a person voluntarily to 
build a trail that connects all the identifiers that 
person uses over time into a single name history. A 
correspondent can then safely name the person by 
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using a potentially obsolete identifier qualified with 
a time at which that identifier was successfully used 
in the past. With this information the appropriate 
name history for a unique person can be found and 
followed to its latest entries, which provide a more 
recent way to reach the sought person. 

HINTS offers mobile people control over forward 
pointers from their old to their current online iden- 
tifiers. Even if an old name belongs in a name 
space maintained by a now-defunct organization, 
that name can still be resolved within HINTS to 
a current identifier for its past owner. This inde- 
pendence of a historical name from the provider of 
its associated name space promotes a robust, persis- 
tent way to refer to people, even when the practical 
names we use in everyday life are neither robust, 
unique nor persistent. 

The goal of this paper is to introduce the con- 
cept of historic naming as a means to address iden- 
tity mobility, and to describe a simple version of 
HINTS that can be deployed using today's technol- 
ogy. However, our current efforts focus on designing 
and implementing a decentralized, more fault tol- 
erant and secure version of HINTS, which we also 
briefiy describe in this paper. 

We proceed by providing an abstract model of the 
current personal online identification landscape, in 
Section ||. In Section ^ we introduce the basic con- 
cepts of HINTS, including the structure of the name 
space, the functionality of the service, and the im- 
plementation considerations involved. We evaluate 
the benefits offered by HINTS in Section |, by de- 
lineating what the service can and cannot do, given 
how personal online identification works today. We 
then elaborate on the next step for HINTS, namely 
security and fault-tolerance, we discuss what addi- 
tional requirements these properties place on online 
service providers, and we sketch an enhanced design 
in Section |^, before we conclude. 



2 A Model For Personal Online Iden- 
tification 

This section outlines the naming model on which 
the historic name-trail service is based. This model 
abstracts the way in which names are currently asso- 
ciated with people online. We also describe the com- 
ponents that currently provide naming services and 
explain the division of control and naming respon- 
sibilities between these services and their clients. 

People need names online for a variety of pur- 
poses, such as authentication, communication, and 
authorization. In most cases, these names are sim- 



ple, such as plain email addresses other 
cases, online names may be two-tiered, starting 
with a primary application-unspecific name, which 
is used to look up application-specific addresses in 
a directory via a directory access protocol such as 
LDAP For simplicity, we take the former ap- 

proach in this paper. Specifically, we use email ad- 
dresses as the primary names of people online in our 
examples. However, the techniques we describe in 
later sections apply directly and without change to 
names in other applications, such as instant messag- 
ing, or to two-tiered naming environments. 

The names people use are drawn from a multi- 
tude of independent name spaces. A name space 
is a set of all possible names that are or can be 
assigned by a single administrative entity, called a 
name-space provider. For example, Yahoo! Inc. is 



the name-space provider operating the yaioo . com 
name space: this is the set of all possible ac- 
count names for Yahoo! Inc.'s services, such as web 
mail, instant messaging, calendaring, etc. In most 
cases, the name-space provider responsible for a 
name is easy to determine from the name itself. 
For example, aame(Syahoo . com is a name in Ya- 
hoo! 's name space. The computers responsible for 
maintaining a name space are the name servers 
of the provider. To find an authoritative name 
server for a name space, we can access the Do- 
either through a distinct 
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main Name Service 
DNS resource record type, or through a straightfor- 
ward name mapping (e.g., names . sample . edu for 
the sample.edu name space). 

A person online may be addressable via multiple 
names drawn from different name spaces. For exam- 
ple, one may be addressed using names assigned by 
a school, by a personal Internet service provider, by 
web services such as Yahoo! and Hotmail, and by 
professional associations such as the ACM. These 
names can be used for distinct or overlapping pur- 
poses: professional, personal, commercial. 

The association of a name with a person fol- 
lows the regulations defined by the corresponding 
name-space provider. These regulations may dic- 
tate whether a name association is temporary or 
permanent, whether a name may be reassigned af- 
ter its previous association is discontinued and, if 
so, the minimum amount of time between succes- 
sive assignments of a single name. For example. 
Sample University's Computer Science Department 
assigns names to its graduates for life, whereas ISPs 
assign names to clients for the duration of the per- 
tinent service agreement. It is important to note, 
however, that the name-space provider is the ulti- 
mate controller of the name space, regardless of the 
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"promises" it makes to those using its names. It is 
not uncommon, for example, that a claimed perma- 
nent name assignment has had to change for legal, 
social or political reasons. As an example experi- 
enced by one of the authors at Sample University, 
the arrival of a new faculty member who desired 
an email address already assigned to a graduate re- 
sulted in a reassignment of that email address to the 
faculty member, in spite of the institution's guaran- 
tee of lifelong identifier assignments to its graduates. 

In most cases today, a person exercises implicitly 
his "stewardship" of a name assigned to him, by 
being able to access the application for which the 
name is assigned. For example, in today's Internet, 
if I can read and send email as nameSyahoo . com, 
then I am assumed to be the person to whom that 
name has been assigned. Though not bulletproof, 
this simplistic form of authentication is widely used 
for signing up in mailing lists, for signing up for web 
services or even for conducting business online. The 
name-space provider can revoke an association be- 
tween a person and his name by stopping that per- 
son from accessing the named service; for example, 
the provider can cancel the associated web email 
account, or change the requisite password. Aside 
from intra-enterprise settings, not many name-space 
providers today offer rigorous security in how they 
assign names, and how their clients assert ownership 
on their names. Section |^ describes a more secure 
naming model, very similar to an attribute certifi- 
cation model, that allows us to address the problem 
more comprehensively. 

In the remainder of this paper, we limit mobile 
person to be someone who wishes to remain reach- 
able despite identifier changes. A correspondent per- 
son is someone who wishes to reach a mobile person. 
In the examples we use, Jane Mobile is a mobile per- 
son, and Dan Friend is a correspondent of Jane's. 



3 A Historic Name- Trail Service 

The primary goal of this work is to provide mo- 
bile people with a forwarding service that is avail- 
able to help them remain reachable despite their 
identity mobility. We accomplish this by allow- 
ing a mobile person to determine to what his his- 
toric names — names qualified with a time when they 
validly named that person — point. We approach 
the problem first by taking the simplest path pos- 
sible: a centralized, trusted service that operates 
similarly to most web services currently deployed 
and works with no cooperation from current infras- 
tructure. We explore more sophisticated, secure and 



fault-tolerant possibilities in Section ^. 

Reachability despite identity mobility requires the 
transfer of some of the naming "power" over a name 
from the associated name-space provider to the per- 
son to whom the provider assigns the name, within 
closely guarded temporal confines. Specifically, even 
though a provider can do anything it wishes to a 
name, its actions cannot be applied retroactively: 
if Yahoo! assigns jmobileOyahoo . con to Jane Mo- 
bile from August 1999 to May 2000, it cannot later 
"change history" so as to strip Jane of her con- 
trol over jmobileOyahoo . com for the indicated time 
period; Jane's authority over jmobileOyahoo . com| 
from August 1999 to May 2000 is persistent. 

By imposing this persistence of authority, HINTS 
splits responsibilities between mobile people and 
name-space providers. Name-space providers are 
responsible for creating and destroying associations 
between names and people (in fact, between names 
and people who can access the service state for that 
name). People are responsible for acting on behalf 
of, and being reachable as a particular name during 
the period that they have been assigned that name. 

This separation of control enables the definition 
of a "virtual" global persistent name space, with 
most of the ambitious properties suggested in Iden- 
tiScape such as persistence, controllability and 
human-centricity, but without requiring the cre- 
ation and maintenance of a centralized name service 
for a global, flat name space implied by that system. 

3.1 The Name Space 

We define the HINTS name space by extending 
names with a continuous time designation. For 
example, to refer to the per son named by the 
identifier "jmobileOyalioo . com in March of 2000 



jmobileQyahoo 



we construct the identifier Historic 

03/2000]. More generally, the HINTS name 
space conta ins identifiers of the form Historic [name® 
time] 



namiespace 



A HINTS name corresponds to a 
time-specific primary name, and is meaningful both 
while the associated primary name is valid (i.e., as- 
signed), and after that primary name has been re- 
assigned or obsoleted by its name-space provider. 

The time component of the identifier defines a 
version of the chosen name space at a particular, 
coarse-grained time. The time component may des- 
ignate an entire year, a year and a month, or a 
full date. Since identifiers change at "human" time 
scales, refining the time component to anything 
shorter than a day may be unnecessary. We as- 
sume that clocks of clients or providers are at least 
coarsely synchronized (e.g., they all agree on what 
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day it is), but we address a more secure timing en- 
vironment in Section ^. 

Many different HINTS names may denote the 
same person. Since Jane Mobile held the name 
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jmobile@yahoo.com from August 1999 to May 
2000, any HINTS name that corresponds to the 
same primary name and with a time designation 
within the validity period points to her. For 
example, H istoric| jmobileOyahoo . comt 9/8/1999] 
and Historic| jmobileOyahoo . com, 1/2000] are valid 
HINTS names for Jane Mobile. 

Some HINTS names denote multiple people. Con- 
sider the scenario in which Ya hoo! Inc. reassigned 
the name jmobileQyahoo . com to a different person, 
James Mobilewski, in September of 2000. T hen the 
HINTS name Historic ljmobileQyahoo . com| , 2000] is 
multivalent^ in the sense that it points to two differ- 
ent people, Jane Mobile and James Mobilewski. A 
multivalent HINTS name is essentially a list name, 
since it names all of the possible people to whom 
the included primary name points during the time 
designation of the historic name. Therefore, historic 
names with narrow time designations are preferable 
to those with very broad time designations, when 
possible. 

3.2 A Personal Naming History 

HINTS relies on a name history to resolve historic 
names. A name history links together HINTS names 
that refer to the same person. The objective behind 
maintaining a name history is to be able to reach a 
currently valid name-to-person association, starting 
with a now obsolete one. In the Jane Mobile exam- 
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pie, the goal is to be able to obtain name janem(? 

otmail.com, which is currently valid and is held 
by Jane, starting with Historic| jmobileSyahoo . com 



03/2002], even though jmobile@yalioo.com is no 
longer held by Jane. Figure |l| shows an example 
name history for Jane Mobile. 

A name history is maintained as a sequence of 
historic records pertaining to a single name within 
a single name space, such as jmobile@yahoo.com. 
An online entity called a name historian maintains 
these records. The history of a name is modified due 
to either assignment changes or linking changes. 

Changes in assignment affect to whom a partic- 
ular name points. These are effected in provider- 
specific ways, such as changes in the password 
needed to receive service under a particular name, 
etc. Assignment changes can be detected by the 
name historian either directly, through an explicit 
notification from the name-space provider, or indi- 
rectly, through failure of a mobile person to respond 



7/2/2000 10/1/2001 



1/3/2002 



janem@ 
hotmail.com 

jane@ 
sample.edu 

jmobile@ 



yah00.com g/i/iggg 5/25/2000 



Figure 1: Jane's name history. Each of the three names 
shown has been held by Jane at some point in time. For 
each name, the thick gray line represents the time pe- 
riod during which Jane was as signed that name by Ya- 
hoo!. For example, Jane held janemOhotmail . con be- 
tween July 2000 and October 2001. 



to a challenge issued to his formerly assigned name. 
Since in this design we assume no cooperation from 
name-space providers, only indirect detection of as- 
signment changes is possible. However, the histo- 
rian can initiate indirect detections of assignment 
changes reactively, at the request of a mobile per- 
son. 

Changes in linking affect how a single person as- 
sumes different online names over time. The his- 
torian emulates the concept of a "person" online 
by maintaining a trail of "personal manifestations" , 
such as knowledge of the same secret password or 
of the secret portion of the same cryptographic key 
pair. Linking represents the intention of such an on- 
line person to be or not to be named by particular 
online names. The mobile person requests explicitly 
to be linked to or unlinked from a name by contact- 
ing the name historian with the appropriate request. 

Assignments and links must both support the as- 
sociation of an online name with the historian's on- 
line representation of a mobile person. Specifically, 
to accept such an association, the historian must 
establish two facts: first that the mobile person 
wishes to assume that name, as communicated di- 
rectly to the historian via a linking request; and, 
second, that the online person has access to that 
name, which the historian can detect indirectly by 
sending a challenge to that name via email (or any 
other applicable protocol) and expecting an appro- 
priate response. 

The historian periodically reestablishes both as- 
signment and linking for an association. Since the 
name-space providers are not aware of the service, 
the historian has no recourse but to poll the name 
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AssociationRecord{ 
Name 
Person 
Start Time 
End Time 
Expiration Time 
Next Link 
Next Assign 



jmobileQyahoo . com 
Jane Mobile 
March 2, 2000 
May 1, 2000 
July 1, 2000 
June 29, 2000 
June 29, 2000 



Link 



Figure 2: An association record representin g the as- 
sociation between Jane Mobile and the name |mobileiS 



yahoo. conj from March 2 to May 1 of 2000. The his- 
torian considers the association valid until July 1 and 



confirmation does not arrive, the association record is 
archived as ending on May 1st. Otherwise, the associa- 
tion record remains active, pushing its end time to July 
1st and its expiration time 2 months later. The dura- 
tion of the time-to-live period of 2 months is arbitrarily 
chosen here and can be modified per name space, per 
person, or per name historian. 



space periodically or in response to user requests, so 
as to establish whether the assumed mobile person 
still has control of his former name. Similarly, to 
avoid cases where a mobile person who becomes un- 
available is assumed to be asserting control over a 
name by default for extended time periods, the his- 
torian expects periodically that person to reassert 
his links actively. 

Figure |^ illustrates an association record, the ba- 
sic building block of a historic name database. The 
specific record identifies Jane Mobile using her first 
and last names, although in practice a person is 
identified by the historian using an internal, pri- 
vate, implementation-specific name space for mo- 
bile person identification that no correspondent ever 
sees. An association record is active if it covers the 
present time (that is, its expiration time is in the 
future). An expired association record is archived 
and becomes immutable. 

Figure ^ illustrates some of the historic associa- 
tions that the name historian maintains for Jane. 
As shown in Figure |l|, the name-space provider for 
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•jmobileQyaliQQ . com| unassigns the name from Jane 
on May 25, 2000. As a result, even though Jane 
wishes to retain the name, as evidenced by the 
link extension she requested to July 1st, the histo- 
rian stores an archived association record that only 
extends up to the last time both the name-space 
provider and Jane agreed on the association, May 
1, 2000. 



'.t/'mez 



[]X] Assignment 



janenn@ 
hotmail.com 



7/2/2000 



Jane Mobile - - - - - - «|p> - - - - 

3/1/2000 5/1/2000 7/1/2000 



jmobile@ 
yahoo.com 



8/1/1999 



5/25/2000 



expects a reconfirmation thereof on June 29. If that hotmail.com 



Figure 3: Th e names jmobile@yahoo.com and janemS 



are linked to the historian's account for 
Jane Mobile (dashed line in the middle). The gray line 
segment covers associations that the historian has ac- 
cepted. 



3.3 The Name Historian 

In this section, we delineate the functionality avail- 
able to users of HINTS. In particular, we describe 
the interface to the name historian itself, its design 
and some implementation details. 

The primary objective of any name service is to 
support name resolution: given a personal identi- 
fier, the service must return a "pointer" to the iden- 
tified person. In the HINTS context, this means 
that HINTS names must be resolved to primary 
names, such as email addresses. If Dan Sender 
wishes to send email to Jane Mobile, he must first 
resolve the HINTS name with which he previously 
reached her successfully (Historic! jmobileOyahoo . 



com, 03/2000]) to a currently valid primary name 



(jajie@sainple.edu). Keeping track of the last time 



an email address was used successfully is arguably 
functionality that current email clients can easily 
offer, and is very similar in complexity to keeping 
track, for example, of the last time a web URL 
was used, which most web browsers do transpar- 
ently by default. Alternatively, correspondents can 
remember an approximate time period when they 
contacted a mobile person and construct a historic 
name accordingly, perhaps by referring to saved cor- 
respondence with the mobile person and extracting 
dates from that correspondence. 

The name historian runs a centralized, trusted 
service maintaining name histories. The historian 
is trusted to check the validity of the name histories 
it stores and to report on those histories when asked. 
Given the naming model we assume in this design 
(see Section ^) , the historian is a powerful compo- 
nent in the network. In Section ^ we examine the 
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shortcomings of having such a centrahzed design, 
and we propose ahernatives in Section based on 
stronger assumptions about name-space providers. 

The historian operates a name space itself, con- 
sisting of the account names of its users. This name 
space, however, is only used to authenticate mobile 
people to the historian and need not be visible ex- 
ternally to the service. The historian manages its 
own name space similarly to how most web services 
manage their account name spaces: a client (mo- 
bile person in this case) signs up online and receives 
an account and a means of authentication, such as 
a password or an asymmetric key pair, for future 
exchanges with the historian. 

To accomplish the task of resolution, the historian 
must also be able to receive link requests from mo- 
bile people as described in the previous section, and 
send and verify challenges to the holders of primary 
names to detect name assignment changes. 

HINTS can help correspondents who must rely 
on their own memory to construct a resolution re- 
quest by presenting them with a history of name 
associations for the same name. For example, Dan 
Friend remembers having contacted Jane in the late 
90's, but that is as specific a time frame as he can 
recall. If he can find out that jmobileSyahoo . com 
belonged to someone from 1995 to 2000, and then to 
someone else from 2000 to 2002, then Dan can rea- 
sonably choose Historic[ jmobileOyahoo . com, 1999] 
to locate Jane Mobile. 

In summary, the history service must be able to 
perform the following tasks: 

• Create mobile person accounts. 

• Request link changes (linking and unlinking) 
between a mobile person account and a primary 
name. 

• Resolve a historic name to a currently assigned 
primary name. 

• Retrieve a list of association periods for a pri- 
mary name. 

The historian maintains a database of associa- 
tion records, as described in the previous section. 
The database maintains two sorted indices, one on 
[name, start time] and another on [person, start 
time] . 

When a mobile person requests to be linked to a 
name, the historian contacts that name with a ran- 
dom number as a challenge, by email or any other 
applicable protocol. If the email is returned with 
the appropriate response to the challenge, then the 
historian considers the name assigned to the mobile 



person and creates a new association record. Algo- 
rithm |l| details this process. 



Algorithm 1: Link mobile person A to name aOA, H 
is the historian, M is the mobile person, now is the 
current time (on the historian's clock) and I is the 
maximum validity period of a link. M is assumed to 
have logged in as A. denotes a network message. 
^ denotes assignment. The process executes on H. 
H ^ M: Link A to 
N ^ random nonce 
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11 

12 

13: 
14: 



H =>a@A: Request confirmation of assignment to 
A with nonce N 

H <^ M: Assignment confirmation of aOA to A 
with nonce N 

if confirmation is negative or none arrives then 
Do nothing and exit 

L ^ the association records where name is a@A 

and person is A with the greatest start time 

if none is found tkien 

Store into database [Association |aQA[ A, now, 
now, now ~\- I, now + I, now -\- l\ {format is 
name, person, start, end, expiration, next link, 
next assignment} 

else 

if ExpirationTime{L) < now then 
Store into database [Association 

now, now, now + I, now + I, now 
else 



aOA, A, 



Upd ate i nto database record L to [Associa- 

A, StartTime(L), now, now + I, 



tion aOA 



now + I, now + l\ 



Links are severed in a similar manner, although 
no confirmation from the associated primary name 
is necessary; the reason for severing a link is exactly 
that the associated primary name is no longer under 
the control of the mobile person and, as a result, a 
confirmation from the primary name might not even 
be possible. However, a notification is sent to the 
primary name, to make it harder for an unautho- 
rized user of the historian account to make changes 
unobtrusively. Algorithm |^ describes the process in 
more detail. 

Correspondents query the historian for resolved 
historic names in a simple request-response proto- 
col. The historian resolves a historic name by, first 
mapping it to an internal account and then finding 
the latest still-valid association from that account 
to a primary name. Algorithm ^ has the details. 

Listing association periods for a name is a 
straightforward operation helped by the database 
indices maintained. 
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Algorithm 2: Sever the hnk from the historian ac- 
count A to name a® A. H is the historian and M is 



the mobile person, logged in as A. 
H ^M: 
H 



Sever 



from A 



aOA: Notification of link severance from A 



L ^ the association record where name is |aQA 
person is A with the greatest start time 
if ExpirationTime(L) > now then 

Upd ate into database record L to [Association 
|a@A|, A, StartTime{L) , now, now, now, now] 



Algorithm 3: Res olve historic name Historic [p.QA| , t] 
to primary name oOB if possible, or return failure 
otherwise. This is run on the historian H. 
1: L ^ the association record where name is aOA 
and the start time s is the highest such that s < t 
if no record is found then 

Return no results 
L' ^ the association record where person is 
Person{L) and the end time is greater than now 
if no record is found then 

Return no results 
Return Name{L') 



4 Discussion 

The name historian we describe in Section ^ achieves 
the primary goal of this work, reachability in the 
face of identity mobility. HINTS accomplishes this 
without the need for brand new globally visible, 
unique, persistent identifiers for every mobile per- 
son. Furthermore, it requires no retrofitting of cur- 
rent name-space providers' practices, requires no co- 
operation whatever from those providers, and can 
be deployed incrementally. 

Unfortunately, the simple centralized approach 
we take here has some shortcomings that can be- 
come significant as an increasing fraction of the 
world's business and fraud are transacted online. 
First, it relies on the honesty of the organization 
that operates the name historian. A centralized, 
centrally operated historian is a single point of fail- 
ure, for failures including corruption, malfunction, 
connectivity disruption or going out of business. 
Second, the scheme offers no tangible assurances for 
the correctness of the information it gives out. For 
example, when a correspondent receives a primary 
name in response to a resolution request, he has to 
take the answer on faith; he has to believe that the 
historian did not invent the association and that the 
historian checked the validity of the association (i.e.. 



issued a challenge to the claimed primary name and 
received a satisfactory response). Third, the scheme 
is only useful to those correspondents and mobile 
people who trust the historian. If no single historian 
is globally trusted, then there is no straightforward 
way to allow any correspondent to reach any mobile 
person. 

Another issue that can potentially affect the util- 
ity of HINTS is its reliance on the correspondents' 
knowledge of past names for a mobile person. If I 
never knew Jane Mobile before, there is no historic 
name that I can use to resolve Jane's current contact 
information. HINTS is not intended as a search en- 
gine for finding contact information for people I have 
never attempted to reach before. We believe that 
web search engines and currently deployed lookup 
services such as Who Where are more appropri- 
ate for that purpose. However, old contact informa- 
tion gathered from such a web search becomes more 
valuable with HINTS, since it can then potentially 
be resolved to current contact information. 

A third issue that affects the potential success of 
HINTS is concern for the privacy of individuals. En- 
tering identifiers into a HINTS name trail is volun- 
tary; if a person wants obsolete identifiers to remain 
so, they need not tell HINTS about those identifiers. 
However, mobile people need to be aware that there 
is a risk that messages sent by correspondents to 
those old identifiers may reach someone else who 
now has control over that old identifier. If those 
messages are potentially sensitive, then mobile peo- 
ple may desire to see a widespread use of HINTS. 
Furthermore, we believe that identifiers inevitably 
"leak out" to the outside world. True protection 
from spam and other threats is better performed us- 
ing other techniques, such as the use of a personal 
communications proxy through which all incoming 
communications may be filtered . 

In the next section, we sketch an enhanced name 
historian design that offers the same functionality 
as what we present in earlier sections, but also alle- 
viates the security and fault-tolerance concerns ad- 
dressed above. We are currently focusing our design 
and implementation efforts on this stronger version 
of HINTS. 



5 A Secure Name Historian 

We believe that the increasing need for online se- 
curity, the rising cost of identity theft and spoofing 
and the evolving standardization projects for secure 
directory access will soon change how name-space 
providers do naming. We expect that providers will 
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act much more like cooperative but competing certi- 
fication authorities in the future; in fact, most large 
enterprises and even some governments [Q do per- 
form naming or digital certification within their own 
realms in this more secure fashion. 

Furthermore, we believe that unconditional trust 
in any centralized service is going to be increasingly 
difficult to digest for security-conscious mobile peo- 
ple. 

In this section we enhance our earlier design for 
a historic name-trail service to address two major 
concerns: First we use cryptography to prevent il- 
legitimate changes in name-to-person associations, 
as can be caused by IP and email address spoofing, 
and eavesdropping on unsecured email. Second, we 
relax the need for trusting the name historian un- 
conditionally, by employing secure time stamping |^ 
and undeniable attestation techniques |^, to limit 
the amount of unobtrusive damage a corrupt histo- 
rian can cause to its clients' name histories. 

We start by describing the stronger and slightly 
more cooperative name-space providers we need for 
this enhanced design, and then outline how our ear- 
lier concerns can be addressed. 



IdentityCertif icate{ 



Issuer 

Subject 

Key 

Start Time 
End Time 
Nonce 
Signature 



yahoo . com 
jmobile 
AB34D9 . . . 
August 1, 1999, 
July 31, 2001, 
2C08A3. . . 

<Issuer, subject, key, 
times and nonce signed 
using yahoo. com 's 
private key> 



Figure 4: The iden tity certificate that linlcs tlie name 
jmobileQyahoo . com to the public key AB34D9 .... 



5.1 Certification Authorities As Name- 
Space Providers 



A certification authority is not much more than a 
name-space provider that accompanies the assign- 
ment of a name to a person with the issuance of a 
signed statement called an identity certificate, such 
as the one shown in Figure |. Note that Jane Mo- 
bile is not mentioned explicitly in the certificate. 
Instead, the provider assigns the name to the per- 
son who knows the secret portion of the public key 
AB34D9 . . . , after having established that Jane Mo- 
bile holds that key. The kind of identity verification 
performed before a name-space provider assigns a 
name to a person's public key is provider-specific 
and out of scope in this paper. 

The name-space provider can revoke an assign- 
ment by publishing a revocation certificate, such as 
that shown in Figure || or by publishing another 
identity certificate for the same name but a differ- 
ent public key. 

Finally, the name-space provider refreshes an as- 
signment by issuing new identity certificates for the 
same name and key before the previous assignment 
expires. 

Besides this basic certification functionality, in 
this environment of higher security awareness we 
assume that name-space providers are cooperative 
with the history service, in the sense that they no- 



RevocationCertif icate{ 



Issuer 

Subject 

Key 

Start Time 

Nonce 

Signature 



yahoo . com 
jmobile 
AB34D9 . . . 
May 25, 2000, 
69C802. . . 

<Issuer, subject, key, 
start time and nonce 
signed using yahoo. com 's 
private key> 



Figure 5: The reyo cation certificate tha t breaks the link 
between the name jmobileOyahoo . com and the public 
key AB34D9 
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tify the historian of name assignment changes by 
conveying to the historian newly issued identity or 
revocation certificates. For replay protection, we 
also assume that each such certificate issued by a 
name-space provider contains a nonce value, which 
in the simplest case is the time of issuance, but can 
also be a random number picked as a freshness chal- 
lenge. 

5.2 Certified Historic Naming 

One straightforward way to address this harder 
naming problem is to make all information that the 
historian maintains signed, so as to prevent illegit- 
imate modifications. To make sure that a corrupt 
historian cannot divert a name trail by changing to 
what historian user accounts point, mobile people 
are represented in name histories by their signing 
key pairs, called person keys, similarly to the ap- 
proach taken in SPKI/SDSI §. In this manner, 
the online representation of a person becomes "the 
person who knows the secret signing key" . 

Namp assignmpnts ran ho natnralljf rpprpspntpd 



with thp idpntity and rpvnpatinn rprtifiratps that 



name-space providers issue. Linking can be repre- 
sented with similar link and severance certificates 
(see Figures ^ and respectively) , signed by mo- 
bile people (i.e., the holders of historian accounts) 
who lay claim on different primary names. Instead 
of storing a single association record per primary- 
name-to-mobile-person association, the historian 
stores all signed certificates delineating the assign- 
ment and the linking time periods that make up an 
association. 

The historian can perform the same tasks as those 
in Section 3.3 with only little more difficulty. For 
example, to resolve a historic name, the historian 
must find an association from the historic name to 
a mobile person and then back from the mobile per- 
son to a currently valid name association, as detailed 
in Algorithm |[ Instead of just locating an associa- 
tion record, the historian must find the appropriate 
certificates justifying the association from the given 
historic name to a person and back to another pri- 
mary name; not only does the historian have to re- 
turn the answer it found — a primary name or a neg- 
ative answer — but it must also return a proof, the 
set of certificates that support its response. The cor- 
respondent must then check that all the statements 
are signed correctly, and that they in fact do support 
a valid resolution, regardless of whether the answer 
was a primary name or a name-not-found response. 

Unfortunately, there are three major issues that 
face clients of such a name historian: the short 



LinkCertif icate{ 

Nsime : jmobile@yahoo.com 

Person Key : E51BB2. . . 

Start Time : March 2, 2000, 

End Time : May 1, 2000, 

Nonce : 6FC3F0. . . 

Signature 1: <N£une , Person Key, 
Times and Nonce 
signed by the current 
key of the name> 

Signature 2: <N£mie , Person Key, 
Times and Nonce 
signed by the current 
key of the historian 
account> 



Figure 6: A link certificate associating name 



imobileiS 



yahoo . con with the person currently represented by key 
E51BB2. . . on 3/2/2000. 



SeveranceCertif icate{ 



Naime 

Person Key 
Time 
Nonce 
Signature 



jmobileOyahoo . com 
E51BB2. . . 
April 25, 2000, 
EE3BF4 . . . 

<Nemie , Person Key, 
Time and Nonce 
signed by the 
person key> 



Figure 7: A severance certificate breaking the link 
between the pe rson currently repre sented by the key 
E51BB2. . . and jmobileSyahoo . con on April 25, 2000. 



10 



DelegationCertif icate{ 

Issuer : E51BB2. . . 

Delegate : D91452. . . 

Time : June 1, 2001 

Nonce : D8306A. . . 

Signature : <Issuer, Delegate, Time 
and Nonce signed using 
both issuing and delegate 
keys> 



Figure 8: A delegation certificate, making the delegate 
key a continuation of the key trail of the issuing key. 



lifetime of digital signatures, the need for tempo- 
ral ordering of historic records, and the need for a 
"closed" , append-only historic database. We elabo- 
rate on all three in turn. 

First, digital signatures have a limited lifetime. 
How does one make sure that a statement signed a 
few years back was correctly signed at the time, even 
though the signing key may have by now expired? 
Some work has been done to make signed documents 
usable even after the pertinent signing key has ex- 
pired |l^. In any case, the client must either 
trust the name-space providers themselves to main- 
tain historic records of when they used what public 
key pair to sign their issued statements, or trust an 
external authority, such as the KASTS Key Archival 
Service [|l3j, to maintain these records. Briefly, this 
service maintains a securely time stamped archive 
of the keys that different name-space providers use 
during their lifetimes, along with the times when 
those keys were used. A client who wishes to verify 
a signed statement, including the certificates we de- 
scribe above, can look up the name of the provider 
and the appropriate time period. The returned key 
can be then used to verify the signature on the state- 
ment. However, it is important to also ascertain 
that the statement was signed while the key found 
was still valid (i.e., before it expired or was revoked). 

The ephemeral nature of digital signatures and 
signing keys also makes it hard to maintain the on- 
line representation of mobile people when the histo- 
rian is not fully trusted, since mobile people must 
change the public keys that represent them regu- 
larly. People do this by issuing and submitting del- 
egation certificates to the historian (see Figure ||, 
delegating their "personhood" from older keys to 
newer ones. Again, timing is of the essence, since 
a delegation must be performed before the previ- 
ous key has to be abandoned, due to expiration or 
compromise. 



Second, any secure historic database must in- 
corporate timing information on when its different 
records were archived. This is necessary for archived 
signatures, as described in the previous paragraphs, 
but also for authorization purposes, in key delega- 
tions or associations. For example, given a historic 
name, to establish the appropriate name associa- 
tion from assignment and linking certificates one 
must have knowledge of the relative temporal order- 
ing of the issuance of those certificates. It must be 
shown that the historic name designates a time after 
an identity certificate and a linking statement cre- 
ated an association between the pertinent name and 
mobile person, but before those certificates expire 
or any potential revocation or unlinking statements 
came in effect. Relative temporal authentication of 
certificates in centralized Q and decentralized 
certificate archives can be invaluable here. 

Briefly, relative temporal authentication uses one- 
way, collision-resistant hash functions, such as SHA- 
1 |16| , to define the temporal ordering from ear- 
lier historic records to later ones. In a sense, a 
tamper-evident linked list is created from all his- 
toric records, so that earlier records appear ear- 
lier in the list. Then regularly picked placeholder 
records from the list are published in a widely wit- 
nessed, secure, write-once publication medium, such 
as a high-circulation newspaper; a verifier who cares 
about when a particular record was appended into 
the historic database can trace the linked list back- 
wards and forwards to find the previous and next, 
respectively, list links published in the newspaper, 
which in turn places the record in question in a 
rough time frame, that is, between the publica- 
tion dates of two newspaper issues in the newspa- 
per example. The collision-resistance and one-way 
property of the hash function used to link records 
together guarantees that once a record has been 
placed in the historic database and the next link 
from the database has been "committed" on a news- 
paper, neither the maintainer of the database nor 
anyone else can tamper with the past, changing 
when records appear to have been incorporated, 
adding or removing records, or modifying the con- 
tents of those records. This is the basic mechanism 
behind secure time stamping Q. 

Third, it is important that the historian be un- 
able to "forget" historic records that it has success- 
fully accepted when they were submitted to it. For 
example, if a name-space provider submits a revo- 
cation certificate to the historian and the historian 
accepts it, it should be unable to deny the existence 
of such a revocation certificate convincingly when 
queried later. Undeniable attestation B] is a cryp- 
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tographic construct that allows clients to verify the 
historian's claimed existence or non-existence of cer- 
tain records. The basic idea there is to construct a 
sorted data structure that allows undeniable attes- 
tations on its contents, that is, proofs that a par- 
ticular element belongs or does not belong to the 
data structure. In the secure HINTS design, the 
database indices are, in fact, undeniable attesters. 

An essential requirement is that attestation 
proofs are significantly shorter in size than the en- 
tire data structure itself. Consider, for example, 
a historic name database that holds a few billion 
certificates for many names and many mobile peo- 
ple. It would be extremely unrealistic to have to 
look through every single record in such a large 
database before being able to conclude no interest- 
ing revocation certificate has been archived there. 
The constructs from the work by Buldas et al. j|] 
and Maniatis and Baker jlj] offer attestations with 
sizes logarithmic in the number of records stored, 
which, for extremely optimistic lifetime and popu- 
larity projections for a service like HINTS, never 
exceed roughly 20 KBytes; this is quite an accept- 
able size for records one expects to receive over the 
network once or twice a day. 

5.3 Status 

The reduced-trust version of the HINTS design, 
and a further completely decentralized HINTS, 
are still under active development. Although we 
have already designed — or implemented from ex- 
isted designs — the tools and techniques we describe 
in the previous section, we have yet to deploy and 
quantify the implementation of this more secure 
HINTS system. 



6 Related Work 

The literature regarding naming in distributed sys- 
tems is vast, so in this section we confine ourselves 
to a sampling of systems and products that attempt 
to provide online names specifically for people. 

An early design of a global name service |]loj de- 
scribes how a global hierarchical name space can be 
implemented across a distributed set of computing 
resources. Our approach is in a sense the opposite: 
we assume there are reasons for many separate name 
spaces to exist, and that people's online identifiers 
will move from one such name space to another. It 
is this identity mobility we address. 

The new Internet domain names ending with 
.narnie are intended to provide a flat global name 



space for individuals that is not associated with 
particular employers and institutions. These names 
could indeed function as the primary names in our 
naming scheme. However, there are still many rea- 
sons why registrants for these names may end up 
changing their online identifiers in any case. Peo- 
ple who fail to pay their bills may lose access to 
their .name identifiers. People who change personal 
names, such as when getting married or taking stage 
names, may want to reflect this by changing their 
online identiflers as well. Moreover, these online 
identifiers may not be the only on line identifiers reg- 
istrants use. A user of a .najie identity may also 
have email service through an employer, and it is 
hard to prevent identifiers from these other name 
spaces from " leaking out" in such a way that corre- 
spondents will not attempt to use them after they 
become obsolete. 

IdentiScape jl^ describes a flat global name space 
for people, in which identifiers do not necessarily re- 
flect their personal names but instead can be a set of 
space-separated words in Unicode. The hope is that 
this name space is large enough to accommodate 
many names per person, for everyone in the world, 
for the next one hundred years. In the back end, 
IdentiScape maintains identity objects, which are 
repositories of access-controlled personal informa- 
tion, such as application-specific addresses, credit 
card numbers and user-specific attributes. In the 
model of Section ^, IdentiScape is a two-tiered nam- 
ing scheme. The authors of IdentiScape list identi- 
fier persistence as one of the desired traits of on- 
line identifiers, but there is nothing to suggest that 
users will not change names within the IdentiScape 
name space or use identifiers from other name spaces 
as well, leaving identity mobility issues unsolved in 
IdentiScape. 

CommonName is one of many online redirec- 
tion services (others are OneName [|l8| and Novell's 
DigitalMe CommonName allows the use of 

common names or phrases instead of URLs or email 
addresses. It also allows the owner of a common 
name to set up different redirection schedules, for 
example, the CommonName "Jane Mobile" is redi- 
rected to Jane's personal email address during the 
weekend but to her work email address on a week- 
day. Further personalization is possible, such as 
maintaining globally accessible bookmarks, notes, 
etc. CommonName provides plug-ins for popular 
email applications and web browsers. A common 
name is first assigned according to availability, but 
then checked by a human for "appropriateness". 
Common names must be "appropriate and relevant 
to [the] subscribers' web and e-mail resources." 
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A CommonName is assigned to an account for the 
duration of the account or the service: 

CommonName is committed to providing 
this service free of charge for as long as it 
is commerciahy viable for it to do so. 

However, once an account is discontinued, its Com- 
monName can be reassigned . 

PingID |]l9| is very similar to IdentiScape [ p^ . 
An identity server, privately held by an owner of an 
identity, is responsible for authorizing (or not) the 
release of information according to whomever is ask- 
ing. The business goals cover the usual applications: 
single sign-on, password management, privacy man- 
agement. PingID does not address identity mobil- 
ity, in that it does not allow reverse lookups from 
obsolete primary names to its own name space. 

Classmates, com Q is a service that allows people 
to register the school or college they attended, the 
military base at which they served, or the company 
for which they worked. This allows people who, for 
example, attended the same class at the same school 
to reconnect in the future. HINTS has very similar 
goals to this venture. We also seek to map a mobile 
person's presence in the past to a current contact; 
however, we take a purely online and more general 
approach, in that a correspondent need not know 
anything more than the mobile person's identifier 
used in the past, rather than first and last names 
and a class year. This makes it easier for email and 
other applications to run identifiers through HINTS 
automatically, perhaps every time they are used, 
to make sure the most recent identifier is accessed, 
although it limits the amount of heuristic weeding 
one can do on likely candidate names. In addition, 
HINTS provides a trail of past identifiers, allowing 
correspondents throughout a recipient's history of 
identifiers to contact the recipient, even if the corre- 
spondents did not know the recipient when he grad- 
uated from Sample University in 1957. 



7 Conclusion 

The extremely volatile environment typical to on- 
line services and their users makes identifier changes 
and the commensurate management problems a 
painful fact of online life. In this paper, we address 
the problem of identity mobility, by extending the 
names people commonly use in today's applications 
with a designation of a time when those names were 
successfully used. 

We present a simple design for HINTS, a his- 
toric name-trail service, that allows mobile people to 



record and make available their movements through 
the "identifier landscape" . Correspondents can fol- 
low those name trails from where a person has been 
(i.e., a name she used to have) to where that person 
is (i.e., a name she uses now). In this way, a cor- 
respondent can resolve a temporally qualified name 
into a name that is valid now; he can use that name 
to reach a mobile person whom he has not contacted 
in a long time, avoiding names that point to no one 
and reassigned names that point to the wrong per- 
son. 

Finally, we describe how security can enhance 
HINTS in the increasingly naughty Internet to pre- 
vent illegitimate use of historic names and name- 
history corruption by a malicious service itself. We 
outline a design for such an enhanced HINTS sys- 
tem, which we hope to evaluate and make available 
soon. 
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